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Reply to Office action of March 01, 2010 

REMARKS/ARGUMENTS 

1. Introduction 

This is a full and timely response to the Office action of March 01, 2010. Rationale 
is presented differentiating current claims over known references. No new material is 
5 introduced. Reconsideration of the application is respectfully requested. 

2. Response to Arguments 

For the purposes of possible appeal, the applicant respectfully maintains arguments 
responded to in the "Response to Arguments" section (Pages 2-3) in this Office action. 
10 For example, the Examiner responds "It is obvious that such fault injecting as a method 

for simulating input data , it can be implemented and/or executed in different environment 
including for debugging Java or BIOS. Crump's method in monitoring and debugging 
code also includes comparing testing results and modifying code being tested (see for 
example, col. 16, lines 40-58). " 

15 

The cited text includes "a typical session might include: (I) setting a 
data-breakpoint or two in the code being developed using the Set Memory Breakpoints 
command, (2) setting an instruction-breakpoint or two and starting execution of the 
code with the Go After Setting Breakpoints command, (3) waiting for a breakpoint, (4) 

20 examining relevant memory and registers using the Display Memory and Display All 
Registers commands (comparing the displayed results with the expected results), (5) 
stepping through the code using the Trace command (comparing the displayed results 
with the expected results), (6) making modifications to the code being developed 
responsive to the comparison of the displayed results to the expected results, and (7) 

25 restarting the system again, thereby beginning the cycle again." 

The applicant respectfully asserts that "(4) examining relevant memory and 
registers using the Display Memory and Display All Registers commands (comparing 
the displayed results with the expected results)" and "(6) making modifications to the 
30 code being developed responsive to the comparison of the displayed results to the 
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expected results" is not the same thing as injecting faults into the system. Additionally, 
the Examiner has not yet shown how a "method/concept" of Sanchez which tests Java 
code and requires a full operating system can reasonably be combined with Crump. 

5 3. Rejections 

Claims 1, 7, 17-19, 21 and 24 are rejected under 35 U.S.C. 103(e) as being 
unpatentable over Crump (US 5,850,562) in view of Sanchez (US 6,477,666) and in 
view ofHundt (US 2004/0205720). 

10 Concerning at least claim 1, the applicant respectfully maintains that Sanchez's fault 

injection methods cannot reasonably be combined with Crump. 

Concerning all claims, and especially claim 17, Crump fails to teach outputting a 
"diagnosis code" as defined in the specification, and fails to meet "executing the BIOS 

15 program code until the diagnosis code of the breakpoint matches a predetermined 
diagnosis code". The specification defines "diagnosis code" as being unique to 
identifying WHICH event is being tested (Paragraph [0031], Step 52). "Examining 
relevant memory and registers using the display memory and . . . comparing the 
displayed results with expected results" (Page 6) is examining program variables, not 

20 which event is being tested, and not the same thing. Crump fails to teach "executing 
the BIOS program code until the diagnosis code of the breakpoint matches a 
predetermined diagnosis code". What Crump teaches is quite similar to the system 
described in paragraphs [0005]-[0006] of the instant application, and does not relate to 
the current claims. 

25 

Concerning at least claim 18, Crump fails to "for each breakpoint, determining 
whether the diagnosis code matches a user defined diagnosis code; and resetting the 
parameter to simulate that the peripheral device is in the error state and executing the 
event corresponding to the diagnosis code according to the reset parameter for making 
30 the event undergo the error processing path when it is determined that the diagnosis 
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code matches the user defined diagnosis code." For at least the reason that Crump 
teaches examining values of program variables, not determining and changing 
program flow according to whether the current event matches a predetermined event. 

5 Concerning at least claim 19, Crump fails to teach "continuing execution of the 

driver program code to a next breakpoint without resetting the parameter when it is 
determined that the diagnosis code does not match the user defined diagnosis code." at 
lease again because Crump teaches examining values of program variables, not 
determining and changing program flow according to whether the current event 
10 matches a predetermined event. 

Concerning claim 22, again Crump fails to teaching determining and changing 
program flow according to whether the current event matches a predetermined event 
according to the specification defined diagnosis code, which claim 22 specifically 
15 defines as "each diagnosis code uniquely indicating the event corresponding to the 

breakpoint". The Examiner merely says "Claims 18-19 and 21-22 are other versions of 
claim method as recited in claim 1". 

20 Furthermore, and concerning all claims, even if one or more of the references 

does somehow associate a particular breakpoint with a particular event, it is not taught 
and certainly does not teach the claimed method. Crump does teach program 
debugging, but as stated in instant paragraph [0008], "A technician needs to set 
many breakpoints in places where bugs might occur, and when running 

25 into a breakpoint, stop executing the program and determine if the result 
of the execution is expected. If not, this means that there are bugs in the 
program codes and the technician must narrow the range to execute the 
same steps to search for program errors." 

30 However, the present claims use the identification of a particular breakpoint not 
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as an end in-and-of itself, but to facilitate debugging by allowing rapid execution of 
particular paths of interest during program execution. A script file may be run during 
execution of the code to be tested. At each breakpoint, the script file can check to see 
if the current event is the event of interest, and if so, change the parameter to cause the 
5 code to be tested to take a particular path. Using the present system, a program can 
easily be fully tested under a variety of scenarios, for example in the case of BIOS 
code, CPU okay, memory okay, keyboard missing, mouse okay, hard drive broken etc. 
As is known to one skilled in the art, no matter how much care is devoted to 
programming the code, often intermittent errors arise only in certain situations. The 
10 current claims allow easy testing of various combinations of program paths to help 
solve this problem. The references alone or in combination fail to do this. 

4. Summary 

The applicant respectfully submits that Crump and Sanchez cannot be properly 
15 combined and the Examiner has not yet shown how a "method/concept" of Sanchez 
which tests Java code and requires a fully functional operating system can reasonably 
be combined with Crump. 

The applicant respectfully further submits that references alone or in combination 
20 fail to properly anticipate determining and changing program flow according to 
whether the current event matches a predetermined event according to the 
specification defined diagnosis code, and which claim 22 specifically defines as "each 
diagnosis code uniquely indicating the event corresponding to the breakpoint". 

25 For at least these reasons, the applicant respectfully requests reconsideration of 

the application and that a timely Notice of Allowance be issued in this case. 
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Sincerely yours, 

/Winston Hsu/ Date: 04/15/2010 

5 Winston Hsu, Patent Agent No. 41,526 

P.O. BOX 506, Merrifield, VA 221 16, U.S.A. 
Voice Mail: 302-729-1562 
Facsimile: 806-498-6673 
e-mail : winstonhsu@naipo.com 

10 

Note: Please leave a message in my voice mail if you need to talk to me. (The time in 
D.C. is 12 hours behind the Taiwan time, i.e. 9 AM in D.C. = 9 PM in Taiwan.) 
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